Understanding Transactional Sub-Processes

Overview

Transactional Sub-Processes facilitate the implementation of business scenarios with transactions that can last many days or weeks until all activities are completed.

From a business perspective, a transaction is a set of activities that constitute a logical unit of operation that must be performed atomically (indivisible). A special protocol ensures that all parties involved agree that the activity should be completed or canceled.

A transactional Sub-Process is performed successfully when changes (updates, additions, or deletions of records) are saved in the database. In other words, changes are committed once the transaction has ended. Exceptions or Cancellation Events are triggered when a transaction is not successfully completed, without affecting database integrity.

Transactions can be short or long, depending on the type of tasks to be executed, which can be automatic or manual.

---

Possible Outcomes of a Transactional BPMN Model

A long-lasting transactional BPMN model has three possible outcomes:

1. Successful Completion

   • All activities in the process are successfully completed, and the process continues with the normal flow.

2. Compensation Execution

   • A failure occurs, requiring all activities that were already completed to be reversed. This is done using compensation activities. Each activity that needs compensation has a task associated with it.
   • Compensation returns the process to its initial state and is only performed if an activity has successfully ended.

3. Exception Handling

   • An unexpected error occurs, interrupting the transactional Sub-Process activities without compensation.
   • The process continues with an Intermediate Error Event.

To model a transactional process, it is necessary to attach Error and Cancel Events to the Sub-Process. If any of these two events occur, the flow will continue.

The edge of a transactional Sub-Process shape is displayed with a double line.

---

Modeling Transactional Sub-Processes

Example: Money Transfer Between Accounts

A typical example is money transfer between bank accounts.

• A debit is performed in one account to credit an amount in another account.
• The debit and credit actions are performed independently using bank-specific interfaces.
• If a problem occurs (e.g., wrong account number or inactive client), the debit must be reversed.
• A new action is required to compensate for the transaction, and the process terminates without funds being transferred.

The process diagram for this scenario:

The Transferring Funds for Disbursement process can have three different outputs: normal, cancellation, and exception.

---

1. Normal Outcome

In a normal process flow, the debit and credit operations are successfully performed.

• Bizagi saves the changes in the database (commit is performed) and continues with the normal process flow.

In the image below, the process performs a fund transfer using a Web Services interface, debiting the amount and crediting it to another account.

• The process then continues with the Activate Credit Task after the transaction is successfully performed.

---

2. Cancellation

A Cancellation Event is triggered when a failure occurs and an exception is thrown.

• The process executes compensation activities and exits the Sub-Process to follow the cancellation flow.
• Data modified within the Sub-Process is not stored in the database, and the process is reversed to the last stage before executing the Sub-Process.

How Cancellation Works:

1. An account is successfully debited through an interface.
2. The system attempts to credit the amount to the customer’s account, but the account number is incorrect.
   • The second interface generates an error, triggering the Cancellation Event.
3. Bizagi executes compensation activities in reverse order of execution.
   • In this case, Compensate Debit reverses the previous Debit task by crediting back the amount.
4. Credit suspension is performed because the fund transfer could not be completed.

Cancellation Events can only be defined for transactional Sub-Processes.

---

3. Compensation Activities

Compensation activities restore the information that was changed in an activity that was successfully performed.

• These compensation activities are usually performed over external systems.
• They are created using the Intermediate Event of Compensation.

---

4. Exception Handling

An exception error occurs when an unhandled error prevents the transactional Sub-Process from continuing.

• Activities are interrupted without compensation.
• The database information is restored to its initial state (rolled back).
• The process continues through the Intermediate Error Event.

How Exception Handling Works:

1. The system attempts to debit the customer’s account, but the server is not responding.
   • The interface generates an error result, triggering the Error Event.
2. The transfer is then performed by phone, concluding the transaction.

Consider the following:

• External interfaces must be compensated properly if they modify external data (via Web Services or a component library).
• Avoid activities that perform reversal for multiple cases because they do not track which activities were successfully completed and which need to be reversed.
• Error Events can only be defined for transactional Sub-Processes.